The present invention relates to methods and apparatuses for improving network traffic in a networked environment. More particularly, the present invention relates, in one or more embodiments, to improvements in Network Packet Brokers and taps and in their implementations.
Network Packet Brokers (“NPB”) and network taps (“taps”) have long been incorporated into networks (such as internal networks and/or the internet) to facilitate processing of data packets and/or to route data packets to/from network monitoring tools. These monitoring tools may include, for example, network analysis tools, forensic tools, various network monitoring tools, firewalls, malware prevention tools, intrusion detection tools, etc.
Generally speaking, taps are implemented at specific points in the network to access the data traffic and pass the data (whether the original data packets or the replicated copies thereof) to the monitoring tools. NPBs, on the other hand, represent hardware and/or software modules that perform, among other tasks, aggregation of monitored traffic (which again can be the original data packets or replicated copies thereof) from multiple links/segments, filtering and grooming of traffic to relieve overburdened monitoring tools, load-balancing traffic across a pool of monitoring tools, and regeneration of traffic to multiple monitoring tools. Both taps and NPBs are available from vendors such as Ixia Corporation of Calabasas, Calif.
To facilitate discussion, FIG. 1 shows a typical network configuration in which a plurality of network devices (such as routers or switches) 102A, 102B, 102C, 102D, 102E, 102F and 102G are shown communicatively coupled to NPB 104. The couplings between network devices 102A-102C with NPB 104 are accomplished using respective mirroring ports 106A-106C such as a SPAN or Switch Port Analyzer ports in the terminology of vendor Cisco Corporation of San Jose, Calif.) on the network devices. Data packets traversing each of NDs 102A-102C may be replicated and provided to respective mirroring ports, which packets are then provided on respective links 108A-108C to respective ingress ports (not shown) of NPB 104. In this configuration, NPB 104 is said to be connected in an out-of-band configuration with respect to packets traversing NDs 102A-102C since the original packets continue on their way without traversing NPB 104 while NPB 104 receives the replicated packets from NDs 102A-102C for forwarding to one or more of the monitoring tools 122 and 124.
Packets traversing between ND 102D and ND 102E can be tapped by tap 110, which is coupled to both NDs 102D and 102E. In one example, the packets from NDs 102D and 102E may be duplicated by tap 110 and provided to NPB 104 via links 108D and 108E respectively. In this configuration, NPB 104 is said to be connected in an out-of-band configuration with respect to packets traversing NDs 102D and 102E since the original packets continue on their way without traversing NPB 104 while NPB 404 receives the replicated packets from NDs 102D-102E.
In another example, the packets from ND 102D may be intercepted by tap 108 and redirected by tap 108 to NPB 104 and from NPB 104 to one or more of the monitoring tools for further forwarding to an analysis tool (such as analyzer 120) before being routed to ND 102E if the result of the analysis indicates that such routing is permissible. Malware detection may be one such type of analysis. In this configuration, NPB 104 is said to be connected in an in-line configuration since NPB 104 is in the data path between ND 102D and ND 102E and packets must traverse NPB 104 before reaching the destination.
FIG. 1 also shows a port aggregator 126, which aggregates packet traffic from NDs 102F and 102G to provide the aggregated packets to NPB 104 via link 124. Again, NPB 104 can be connected in-line with respect to the communication between NDs 102F and 102G (i.e., NPB 104 can be in the network data path), or NPB 104 can be connected in an out-of-band manner with respect to the communication between NDs 402F and 102G (i.e., NPB 104 receives only the replicated packets and the original packets continue on their way without traversing NPB 104).
As is well known, certain types of communication require a certain level of Service Level Agreement (SLA) with respect to, for example, delay and/or jitter and/or packet drop rate and the like. These SLAs may be agreed upon between the users and the network operator, for example. For certain types of communication, such as voice or video for example, the jitter parameter must be tightly controlled as packets traverse the network from the origination point to the destination point in order to ensure a high quality session. As another example, financial data packets (such as buy/sell orders) often require as little delay as possible. As yet another example, backup data packets may not tolerate any packet loss while a videoconferencing session may suffer some packet loss without undue detrimental results. These packet transmission specifications for packets associated with a given communication session may be accommodated using an appropriate SLA.
Although NPBs and taps are currently part of the network and are disposed in the communication paths thereof, little attention has been paid to ensure that their involvement does not detrimentally affect the required SLA of the packets involved.
Further, even if SLAs are not involved, the monitoring tools to which the NPBs forward the packets may have certain capabilities and/or requirements. Currently, little attention has been paid to ensure that packets are forwarded by the NPBs to the tools comply with these tool capabilities and/or requirements. Likewise, the network may have certain capabilities and/or requirements for the forwarding of the packets by the NPBs. These requirements need to be observed if the NPBs are to be truly integrated into the network.
For these reasons and others, improvements in NPBs and taps and in their implementations are desired.